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ABSTRACT 


Improvised  Explosive  Deviees  eontinue  to  harass,  maim,  and  kill  innoeent  men,  women, 
and  ehildren,  as  well  as  numerous  eoalition  and  U.S.  forees.  To  eombat  this  terror,  the 
U.S.  government  has  employed  significant  resources  across  a  diverse  range  of  dedicated 
researchers  and  testers.  The  urgency  of  their  task  cannot  be  overemphasized.  However, 
in  working  so  diligently  to  test  the  separate  components  of  a  defeat  system,  it  is 
hypothesized  that  opportunities  are  being  missed  which  could  effectively  utilize  all  of  the 
information  available  across  the  test  enterprise.  The  purpose  of  this  thesis  is  to  identify 
the  organizations  and  activities  involved,  the  information  shared,  and  the  processes 
employed  by  organizations  within  the  JIEDDO  Test  Board  (JTB).  The  objective  is  to 
provide  an  accurate  representation  of  the  process,  and  where  the  main  decision  points  and 
bottlenecks  occur.  The  conclusions  achieved  by  this  research  are  provided  to  enhance  the 
JIEDDO  test  process  system.  The  goal  of  this  study  of  the  JIEDDO  process  is  to 
contribute  to  improving  information  sharing  and  knowledge  management  among 
stakeholders  involved  in  the  JIEDDO  Test  Board  Enterprise. 
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I.  INTRODUCTION 


A.  BACKGROUND 

This  research  was  conducted  to  provide  a  Joint  organization  within  the 
Department  of  Defense,  a  snapshot  of  its  process  from  the  perspective  of  the  end  users.  It 
is  intended  to  be  a  representation  of  the  support  and  products  provided,  and  how  the 
support  and  products  are  utilized  by  the  end  users. 

1.  The  Threat 

Improvised  Explosive  Devices  (lEDs)  continue  to  harass,  maim,  and  kill  innocent 
men,  women,  and  children,  as  well  as  U.S.  and  Coalition  forces  in  Iraq  and  Afghanistan. 
Currently  over  60%  of  U.S.  casualties  are  caused  by  lEDs  {Military  Casualty 
Information,  2011).  The  urgency  of  this  task  cannot  be  overemphasized.  lEDs  have 
been,  and  continue  to  be  a  steady  threat  to  U.S.  personnel,  while  the  War  on  Terror 
continues.  U.S.  casualties  related  to  lEDs  have  consistently  increased  since  the 
beginning  of  the  War  on  Terror,  from  12  in  2001  to  499  in  2010  {Military  Casualty 
Information,  2011).  As  of  2010,  1446  U.S.  service  members  and  2281  total  U.S.  and 
Coalition  service  members  have  been  killed  as  a  result  of  lEDs  {Military  Casualty 
Information,  2011). 

2.  The  Response 

The  U.S.  Government  has  employed  significant  resources  across  a  diverse  range 
of  dedicated  researchers,  developers,  and  testers  to  create  tools  to  combat  the  terror  of 
lEDs  and  counter  the  lED  threat.  One  response  to  the  lED  threat  by  the  U.S.  Government 
was  to  create  an  organization  tasked  with  countering  the  lED  threat.  The  Secretary  of 
Defense  signed  DoD  Directive  2000. 19E,  which  directed  the  development  of  the  Joint 
Improvised  Explosive  Device  Defeat  Organization  (JIEDDO),  a  joint  organization 
designed  to  combat  the  lED  threat  (U.S.  Department  of  Defense,  2006).  The  Directive 
which  created  JIEDDO,  states  that  JIEDDO  shall  focus  (lead,  advocate,  and  coordinate) 
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all  Department  of  Defense  actions  in  support  of  the  Combatant  Commanders’  and  their 
respective  Joint  Task  Forces’  efforts  to  defeat  Improvised  Explosive  Devices  as  weapons 
of  strategic  influence.  Under  this  directive,  JIEDDO  has  developed  its  creed:  “Attack  the 
Network;  Defeat  the  Device;  Train  the  Eorce  (from  U.S.  Department  of  Defense,  2011).” 

3.  The  Organization 

DoD  Directive  2000. 19E  gives  JIEDDO  the  authority  to  form  functional  boards 
that  perform  specific  roles  to  assist  JIEDDO  in  accomplishing  its  mission.  In  total  the 
Directive  assigns  duties  and  responsibilities  to  seven  separate  boards,  groups  and  teams. 
One  such  board  is  the  Joint  Improvised  Explosive  Device  Defeat  Organization  Test 
Board  (JTB)  and  will  be  the  focus  of  this  research.  This  DoD  Directive  gives  the  JTB  the 
authority  to  synchronize  all  testing  and  evaluation  events  which  fall  under  JIEDDO 
influence  and  to  coordinate  with  military  departments  to  quell  the  possibility  of  redundant 
testing,  under  five  specific  areas  of  authority,  consisting  of: 

•  Track  and  identify  all  JIEDDO  test  events. 

•  The  use  of  testing  sites  and  laboratories  in  order  to  collaborate,  thus 
decreasing  redundancy  of  testing 

•  Scheduling  authority  for  testing  events 

•  Coordination  and  reporting  of  new  technology  assessments  to  the 
Combatant  Commanders 

•  Provide  recommendations  to  the  JIEDDO  Integrated  Program  Team  (U.S. 
Department  of  Defense,  2006,  p.  16,  17) 

Adhering  to  these  five  areas  of  authority,  the  JTB  conducts  its  operations  as  a  multiple 
organization  enterprise. 

4,  The  Enterprise 

The  JTB  is  global  in  nature  as  are  the  associated  organizations,  personnel,  and 
processes.  The  JTB  does  not  have  direct  authority  over  the  organizations  it  is  associated 
with  yet  it  is  dependent  upon  those  organizations  in  order  to  perform  its  mission.  It  is  due 
to  this,  that  the  JTB  has  become  an  enterprise,  and  will  be  called  as  such,  the  JTB 
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Enterprise,  throughout  this  thesis.  In  the  context  of  this  thesis,  the  term  JTB  will  be  used 
to  describe  the  personnel  assigned  to  roles  that  provide  direct  support  to  the  JTB  Director. 
These  personnel  support  the  Director  by  providing  guidance  and  oversight  to  the  areas  of 
authority  set  forth  for  the  JTB  by  the  Directive.  The  JTB  bridges  the  gap  between  the 
deployed  elements  of  the  JTB  Enterprise  and  the  test  sites.  There  are  other  areas  of  the 
JTB  Enterprise,  which  provide  the  JTB  Director  information  as  well.  Eor  example,  the 
JTB  employs  the  use  of  working  groups  who  perform  specific  tasking  that  gives  the 
Director  information,  and  that  can  then  be  used  to  develop  testing  protocols  ensuring  the 
most  effective  tests  are  conducted. 

The  end  user,  in  the  context  of  this  research,  is  defined  as  a  person  or  organization 
that  interacts  (directly  or  indirectly)  with  the  JTB.  The  end  user  consists  of  personnel 
deployed  to  areas  where  the  threat  of  an  lED  is  heightened.  End  users  are  not  restricted 
solely  to  the  troops  in  harm’s  way;  end  users  can  also  be  the  organizations  who  provide 
support  to  the  end  user. 

Theater  support  elements  are  organizations  that  provide  both  the  end  user  and  the 
JTB  with  information,  which  will  assist  in  the  counter  lED  fight.  The  theater  support 
elements  are  a  vital  portion  of  the  JTB  as  these  organizations  provide  access  for  the  JTB 
to  the  end  user  as  well  as  a  means  for  the  end  user  to  reach  out  to  the  JTB.  There  are  also 
times  when  these  organizations  will  act  as  the  end  user  and  in  those  cases  the  terms, 
theater  support  elements,  and  end  users,  can  be  interchanged. 

The  test  sites  are  organizations  associated  with  the  JTB  Enterprise  and  consist  of 
open-air  test  centers,  laboratories,  academic  institutions,  and  modeling  and  simulation 
laboratories.  In  some  cases,  various  test  sites  are  used  simultaneously  for  the  JTB  to 
execute  its  tasking;  therefore,  the  term  test  site  may  refer  to  one  or  more  of  the  testing 
organizations. 
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B,  THE  JOINT  IMPROVISED  EXPLOSIVE  DEVICE  TEST  BOARD 

In  working  diligently  to  test  the  separate  eomponents  of  an  lED  defeat  system,  the 
pereeption  is  that  opportunities  may  be  missed  to  coordinate,  collaborate,  and  cooperate. 
Exploiting  these  opportunities  could  increase  the  effectiveness  of  the  information 
available  across  the  JTB  Enterprise.  If  an  appropriate  collaboration  process  and  tool  set 
were  available,  it  is  hypothesized  that  the  test  centers  and  supporting  research 
organizations  would  be  able  to  provide  better  support  to  the  end  users.  This  process 
improvement  could  increase  understanding  of  the  capabilities  and  limitations  for  the 
various  lED  defeat  products,  and  lead  to  more  effective  lED  mitigation  at  Eorward 
Operating  Bases.  It  is  theorized  that  an  analysis  of  the  JTB  Enterprise  and  its  processes 
from  the  perspective  of  the  end  user,  will  result  in  better  support  to  the  end  user.  The 
objective  is  to  research  the  manner  of  interaction  the  JTB  currently  has  with  the  end  user, 
and  upon  uncovering  this  interaction  it  is  believed  the  JTB  will  have  a  better 
understanding  how  its  products  are  used.  This  knowledge  could  then  be  used  by  the  JTB 
to  evaluate  its  processes,  thus  improving  the  support  needed  by  the  end  user. 

While  the  JTB  enterprise  is  involved  with  several  different  types  of  test  and 
associated  processes,  there  is  one  JTB  process  that  is  prevalent.  The  Request  for 
Information  (REI)  process  is  the  most  common  one  employed  by  the  JTB  and  is  at  the 
heart  of  all  JTB  activities.  This  research  focuses  on  the  REI  process. 

C.  APPROACH  TO  RESEARCH 

Determining  how  the  end  user  uses  the  products  and  processes  of  the  JTB 
Enterprise  requires  an  analytical  approach.  It  is  believed  that  an  analysis  of  the  JTB,  to 
include  its  organizational  structure,  processes,  and  information  flow,  would  yield  results 
applicable  to  both  the  JTB  and  the  end  user.  The  most  efficient  way  to  meet  the  research 
objectives  was  by  examining  the  JTB  as  an  Enterprise.  The  analysis  was  conducted  by  a 
three  step  process.  The  first  step  was  to  attain  an  overall  perspective  of  the  JTBs  through 
interviews  and  academic  research.  The  second  step  was  to  structure  the  information 
gathered  by  the  interviews  in  accordance  with  the  Department  of  Defense  Architecture 
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Framework  (DoDAF)  using  a  software  tool  with  the  capabilities  for  modeling  and 
simulation.  The  third  step  was  to  analyze  this  structure  through  the  modeling  and 
simulation  capabilities  of  the  software  tool. 

The  interviews  were  conducted  onsite  with  various  participants  within  the  JTB,  as 
well  as  Subject  Matter  Experts  (SMEs)  throughout  the  JTB  Enterprise.  The  information 
that  was  gathered  through  the  interview  process  was  critical  to  complete  the  analysis  and 
resulted  in  various  recommendations  to  the  JTB.  The  key  findings  and  recommendations 
are  given  in  the  hopes  of  giving  the  JTB  the  capability  to  provide  better  support  to  the 
end  user. 
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II.  LITERATURE  REVIEW 


The  objective  of  this  research  is  to  provide  an  end-user  perspective  of  the  JTB 
information  flow  process.  The  method  used  to  accomplish  this  objective  was  to  display 
the  JTB  as  an  enterprise  in  accordance  with  the  Department  of  Defense  Architecture 
Framework  (DoDAF).  This  chapter  provides  a  review  of  information  sharing,  knowledge 
management,  enterprise  architecture,  and  DoDAF. 

A,  INFORMATION  SHARING 

One  of  the  focal  points  of  this  research  was  to  determine  how  information  is 
shared  throughout  the  JTB  Enterprise.  To  provide  clarity,  a  distinction  between 
information  and  knowledge  is  needed.  Information  and  knowledge  are  two  terms  that  are 
often  used  interchangeably;  however,  information  is  separate  from  knowledge,  as 
information  is  data  that  is  given  context,  and  knowledge  is  information  that  is  given 
meaning;  thus  information  is  the  heart  of  knowledge.  Information  flow  can  be  aided  or 
impeded  through  the  use  of  tools  such  as  the  strategy  implemented  to  facilitate 
information  sharing,  the  organizational  structure  and/or  the  technical  infrastructure.  The 
research  in  this  thesis  will  cover  the  strategy  and  organizational  structure  while  the 
technical  infrastructure  will  be  examined  by  a  complimentary  thesis. 

1.  Strategy 

The  Department  of  Defense  instituted  an  Information  Strategy  in  2007  in  response 
to  a  recommendation  from  the  Quadrennial  Review  Board  of  2006  (U.S.  Department  of 
Defense,  2007,  p.  2).  The  goal  of  the  strategy  is  to  create  an  environment  within  the  DoD 
that  will  promote  sharing,  achieve  an  extended  enterprise,  strengthen  agility,  and  instill 
trust  among  DoD  organizations  (U.S.  Department  of  Defense,  2007,  p.  5). 
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2,  Organizational  Structures 

The  structure  of  an  organization  can  dictate  how  the  information  flows  through 
the  organization.  There  are  five  components  to  an  organization:  the  strategic  apex  (top 
management),  the  middle  line  (intermediate  managers),  the  operating  core  (operators  of 
the  organization),  the  technostructure  staff  (analysts  and  system  designers),  and  the 
support  staff  (providers  of  indirect  services  to  the  organization)  (Mintzberg,  1981,  p.  3). 
Organizations  can  be  structured  in  five  different  configurations:  a  simple  structure,  a 
machine  bureaucracy,  a  professional  bureaucracy,  a  divisionalized  form,  and  an 
adhocracy  (Mintzberg,  1981,  p.  4).  The  machine  bureaucracy  emphasizes  the 
standardization  of  work  for  coordination  resulting  in  low  skilled  yet  specialized  jobs 
(Mintzberg,  1981,  p.  7).  The  divisionalized  form  is  a  group  of  independent  organizations 
loosely  joined  which  is  characterized  by  an  incomplete  structure  (Mintzberg,  1981,  p.  8). 
The  simple  structure,  machine  bureaucracy,  and  professional  bureaucracy  are  defined 
later  in  this  section.  The  focus  of  this  research  is  on  the  operating  core  and  the 
technostructure  components  and  the  simple  structure,  professional  bureaucracy,  and  the 
adhocracy  as  the  two  components  and  the  three  configurations  which  most  closely  relate 
to  the  JTB. 

A  simple  structure  is  composed  of  one  large  unit  with  minimal  top  level  managers 
who  have  oversight  of  a  group  of  operators  who  perform  the  functions  of  the  organization 
(Mintzberg,  1981,  p.  5).  Key  characteristics  of  a  simple  structure  organization  include 
flexibility  and  highly  centralized  control.  Being  a  flexible  organization  allows  the 
organization  to  adapt  to  a  dynamic  environment  in  which  the  organization  may  be 
operating;  however  this  can  lead  to  little  formalization  and  little  training.  The  centralized 
control  means  that  all  information  that  flows  through  the  organization  flows  through  the 
strategic  apex  of  the  organization  (Mintzberg,  1981,  p.  5). 

A  professional  bureaucracy  is  a  configuration  arranged  by  the  standardization  of 
skills  vice  the  processes,  therefore  most  of  the  control  is  given  to  the  personnel  who 
perform  the  tasks,  however,  the  standardization  of  the  skills  provides  for  little  flexibility 
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(Mintzberg,  1981,  p.  8).  The  professional  bureaueraey  relies  heavily  on  its  operating  eore 
whieh  eonsists  of  highly-speeialized  personnel  who  require  a  great  deal  of  training  and 
indoetrination.  This  type  of  eonfiguration  operates  well  in  a  eomplex  but  stable 
environment  where  personnel  require  little  formalization  and  eoordination  as  the 
personnel  are  able  to  work  autonomously  (Mintzberg,  1981,  p.  8). 

An  adhoeraey  is  a  eonfiguration  that  is  eomplex  and  non-standardized  yet  fluid. 
Similar  to  the  professional  bureaueraey,  the  adhoeraey  relies  heavily  upon  speeialized 
personnel  to  perform  its  duties;  however,  in  this  ease  the  speeialized  personnel 
eommunieate  aeross  domains  via  the  use  of  integration  rules  set  forth  by  the  organization 
(Mintzberg,  1981,  p.  10).  It  ean  be  defined  as  adaptable  to  dynamie  situations  due  to  the 
informal  nature  of  eommunieations  between  the  operators  of  the  organization.  This 
ereates  an  environment  where  the  speeialized  personnel  must  work  together  in  order  to 
aeeomplish  tasks  as  the  power  of  an  adhoeraey  is  dispersed  throughout  the  organization 
(Mintzberg,  1981,  p.  10). 

3.  Collaborative  Environments  and  Organizations 

Information  sharing  in  organizations  is  typieally  eondueted  in  a  eollaborative 
environment.  Collaboration  is  the  efficient  and  effective  manner  in  which  organizations 
work  together  internally  and  externally  and  is  practiced  at  all  levels  of  an  organization 
(Beyerlein,  2003,  p.  13).  A  collaborative  organization  is  designed  to  allow  information  to 
flow  easily  throughout  the  organization.  Benefits  of  a  collaborative  environment  include 
empowered  personnel,  as  they  do  not  require  direct  supervision,  improved  processes,  as 
personnel  take  it  upon  themselves  to  solve  problems,  and  better  support  to  the  end  user, 
as  personnel  and  end  users  collaborate  which  maximizes  support  (Beyerlein,  2003,  p.  25). 

Collaborative  organizations  are  built  upon  the  ten  principles  listed  in  Table  1. 


9 


Table  1.  Principles  of  Collaborative  Organizations  (From  Beyerlein,  2003,  p.  34) 


Focus  collaboration  on  achieving  business  results 


Align  organizational  support  systems  to  promote  ownership 


Articulate  and  enforce  “a  few  strict  rules” 


Exploit  the  rhythm  of  convergence  and  divergence 


Manage  complex  tradeoffs  on  a  timely  basis 


Create  higher  standards  for  discussions,  dialogue,  and  information  sharing 


Foster  personal  accountability 


Align  authority,  information,  and  decision  making 


Treat  collaboration  as  a  disciplined  process 


Design  and  promote  flexible  organizations 


Three  of  the  principles  listed  in  Table  1  will  be  elaborated  upon  in  order  to  keep 
within  the  scope  of  this  research.  The  third  principle,  articulate  and  enforce  “a  few  strict 
rules,”  involves  developing  governance  for  the  organization  thus  providing  direction  and 
guidance  to  members  of  the  organization.  The  “few  strict  rules”  should  not  constrain  or 
inhibit  personnel  in  performance  of  their  duties.  The  rules  should  be  a  set  of  parameters 
which  would  provide  personnel  enough  freedom  to  accomplish  tasking,  yet  structured  to 
align  with  the  strategic  goals  of  the  organization  (Beyerlein,  2003,  p.  39).  The  sixth 
principle,  create  higher  standards  for  discussion,  dialogue,  and  information  sharing,  gives 
the  organization  the  ability  to  discuss  and  consider  alternatives  to  increasingly  complex 
problems.  Solving  complex  problems  in  an  unpredictable  environment  is  possible  in  a 
collaborative  organization  since  the  information  needed  to  make  decisions  is  both 
available  and  accessible  (Beyerlein,  2003,  p.  43).  The  ninth  principle,  treat  collaboration 
as  a  disciplined  process,  promotes  the  ability  to  continually  monitor  and  improve  the 
process.  This  increases  the  likelihood  that  all  stakeholders  involved  in  the  process  have 
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common  information.  Therefore,  the  deeisions  made  based  on  the  common  information 
are  more  apt  to  be  trusted  at  all  levels  of  an  organization  since  the  decision  is  the  result  of 
a  collaborative  effort  (Beyerlein,  2003,  p.  49). 

B,  ENTERPRISE  ARCHITECTURE 

An  enterprise  is  a  group  of  associated  organizations  and/or  activities  that  ineludes 
the  people,  information,  and  teehnology  that  provide  a  service  to  a  customer  or  end  user. 
Enterprises  are  structured  in  different  ways  that  depend  upon  the  number  of 
organizations,  people,  and  proeesses  involved  whieh  are  needed  to  allow  the  enterprise  to 
function.  The  structure  of  an  enterprise  is  its  architeeture  and  within  this  arehiteeture  are 
the  guiding  principles  upon  whieh  the  organization  was  founded  (Minoli,  2008,  p.  54). 
The  prineiples  may  or  may  not  be  apparent  by  the  arehiteeture  of  the  enterprise. 
Principles  that  are  not  explicitly  stated  in  the  architecture  would  have  been  used  to 
develop  the  framework.  The  framework  is  the  tool  used  to  describe  the  enterprise’s 
architeeture.  There  are  many  accepted  frameworks  in  use  around  the  world;  this  thesis 
will  use  the  DoD  Architecture  Framework  (DoDAF). 

An  enterprise  arehiteeture  framework  is  a  means  to  represent  all  aspects  of  the 
enterprise.  To  aeeurately  deseribe  the  enterprise  the  framework  must  have  an 
overarching  set  of  standards  or  a  strategy  to  govern  the  interactions  associated  with  the 
enterprise  (Minoli,  2008,  p.  70).  The  govemanee  of  the  enterprise  should  be  generated 
and  enforced  by  a  Chief  Information  Officer/Chief  Teehnology  Offieer  (CIO/CTO)  and 
should  eover  the  principles  in  Table  2,  whieh  has  been  legislated  by  the  Clinger-Cohen 
Aet(1996). 
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Table  2.  Enterprise  Architecture  Principles  (From  Minoli,  2008,  p.  64) 


Architectures  must  be  appropriately  scoped,  planned,  and  defined  based  on  the  intended  use 

Architectures  must  be  compliant  with  the  law  as  expressed  in  legislative  mandates,  executive  orders, 
federal  regulations,  and  other  federal  guidelines. 

Architectures  should  facilitate  change 

Architectures  set  the  interoperability  standard 

Architectures  provide  access  to  the  information  but  must  secure  the  organization  against  unauthorized 
access 

Architectures  must  comply  with  the  privacy  act  of  1974 

Enterprise  architectures  must  reflect  the  agency’s  strategic  plan 

Enterprise  architectures  coordinate  technical  investments  and  encourage  the  selection  of  proven 
technologies 

Architectures  continuously  change  and  require  transition 

Architectures  provide  standardized  business  processes  and  common  operation  environments 

Architecture  products  are  only  as  good  as  the  data  collected  from  subject  matter  experts  and  domain 
owners. 

Architectures  minimize  the  burden  of  data  collection,  streamline  data  storage,  and  enhance  data  access 

Target  architectures  should  be  used  to  control  the  growth  of  technical  diversity 

When  developing  the  enterprise  architecture  the  CIO/CTO  can  base  the 
governance  of  the  enterprise  on  the  ideas  covered  in  Table  3. 

Table  3.  Enterprise  Architecture  Development  Considerations  (From  Minoli,  2008,  p.  71) 

Description  of  the  purpose  and  value  of  an  enterprise  architecture 

Description  of  the  relationship  of  the  enterprise  architecture  to  the  agency’s  strategic  vision  and  plans 

Description  of  the  relationship  of  the  enterprise  architecture  to  capital  planning,  enterprise  engineering,  and 
program  management _ 

Translation  of  business  strategies  into  enterprise  architecture  goals,  objective,  and  strategies _ 

Commitment  to  develop,  implement,  and  maintain  an  enterprise  architecture _ 

Identification  of  enterprise  architecture  compliance  as  one  criterion  for  new  and  ongoing  investments _ 

Overview  of  an  enforcement  policy _ 

Security  practices  to  include  certification  and  accreditation _ 
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The  CIO/CTO  should  also  consider  the  enforcement  policy  questions  in  Table  4. 


Table  4.  Enterprise  Architecture  Policy  Development  Questions  (From  Minoli,  2008,  p. 

71) 

How  and  when  will  projects  submit  project  plans  to  be  reviewed  for  enterprise  architecture  compliance? 

Who  will  be  responsible  for  compliance  assessment  or  justification  of  waivers? _ 

How  will  compliance  and  noncompbance  be  documented  and  reported? _ 

How  will  outstanding  issues  of  noncompbance  be  resolved  or  wavers  be  processed  and  approved? _ 

Who  will  be  responsible  for  processing,  authorizing,  and  reassessing  waivers? _ 

What  will  be  the  content  and  format  of  waiver  submissions? _ 

If  a  waiver  is  granted,  how  will  projects  achieve  compliance  in  the  future? _ 

What  are  the  ramifieations  if  a  noneompbant  projeet  is  not  granted  a  waiver  (e.g.,  funding  or  deployment 
restrietions)? _ 


There  are  two  complimentary  views  of  an  enterprise  architecture.  The  first  is  that 
an  enterprise  architecture  provides  the  organizing  logic  for  processes  and  the  information 
technology  infrastructure  that  correspond  to  the  integration  and  standardization 
requirements  of  the  organizations  operating  model  (Ross,  2006).  The  second  is  that  an 
enterprise  architecture  is  a  blueprint  that  defines  the  structure  and  operation  of  an 
organization  with  the  intent  of  determining  the  most  effective  employment  of  the 
organizations  resources  (Ross,  2006).  Figure  1  provides  an  example  of  a  way  to  organize 
an  enterprise  based  upon  the  amount  of  integration  and  standardization  required  for  the 
enterprise  to  meet  its  goals. 
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Coordination 

•  Shared  customers,  products,  or 
suppliers 

•  Impact  on  other  business  unit 
transactions 

•  Operationally  unique  business  units 
or  functions 

•  Autonomous  business  management 

•  Business  unit  control  over  business 
process  design 

•  Shared  customer/supplier/product 
data 

•  Consensus  processes  for  designing 

IT  infrastructure  services: 

IT  application  decisions  made  in 
business  units 

Unification 

•  Customers  and  suppliers  may  be 
local  or  global 

•  Globally  integrated  business 
processes  often  with  support  of 
enterprise  systems 

•  Business  units  with  similar  or 
overlapping  operations 

•  Centralized  management  often 
applying  functional/process/business 
unit  matrices 

•  High-level  process  owners  design 
standardized  processes 

•  Centrally  mandated  databases 

•  IT  decisions  made  centrally 

Diversification 

•  Few,  if  any,  shared  customers  or 
suppliers 

•  Independent  transactions 

•  Operationally  unique  business  units 

•  Autonomous  business  management 

•  Business  unit  control  over  business 
process  design 

•  Few  data  standards  across  business 
units 

•  Most  IT  decisions  made  within 
business  units 

Replication 

•  Few,  if  any,  shared  customers 

•  Independent  transactions  aggregated 
at  a  high  level 

•  Operationally  similar  business  units 

•  Autonomous  business  unit  leaders 
with  limited  discretion  over  processes 

•  Centralized  (or  federal)  control  over 
business  process  design 

•  Standardized  data  definitions  but 
data  locally  owned  with  some 
aggregation  at  corporate 

•  Centrally  mandated  IT  services 

Low  High 


Business  process  standardization 


Figure  1.  Business  Proeess  Integration  vs.  Business  Process  Standardization 

(From  Ross,  2006,  p.  29) 

1,  Department  Of  Defense  Architecture  Framework 

The  Department  of  Defense  Architecture  Framework  (DoDAF)  was  developed  to 
provide  a  set  of  architecture  techniques  that  will  assist  in  supporting  the  decision  makers 
(U.S.  Department  of  Defense,  2007,  Vol.  1,  p.  5).  It  is  designed  for  all  major  DoD  and 
military  organizations  as  a  means  to  offer  structure  and  give  a  representation  of  how  an 
organization  interacts  internally  and  with  other  organizations  (U.S.  Department  of 
Defense,  2007,  Vol.  1,  p.  5).  DoDAF  employs  viewpoints  that  cover  functional  areas 
related  to  the  architecture  of  an  enterprise.  The  eight  different  viewpoints  available 
within  DoDAF  are  described  in  Table  5. 
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Table  5.  DoD  Architecture  Framework  Viewpoint  Description  (From  U.S.  Department  of 

Defense,  2007,  Vol.  1,  p.  21-22) 


Viewpoint 

Description 

All 

Contains  overarching  aspects  of  the  architecture  as  related  to  all  of  the  viewpoints 

Capability 

Articulates  the  capability  requirements,  the  delivery  timing,  and  the  deployed  capability 

Data  and 

Information 

Articulates  the  data  relationships  and  alignment  structures  in  the  architecture  content  for 
the  capability  and  operational  requirements,  system  engineering  processes,  and  systems 
and  services 

Operational 

Includes  the  operational  scenarios,  activities,  and  requirements  that  support  capabilities 

Project 

Describes  the  relationships  between  operational  and  capability  requirements  and  the 
various  projects  being  implemented 

Services 

The  design  for  solutions  articulating  the  Performers,  Activities,  Services,  and  their 
Exchanges,  providing  for  or  supporting  operational  and  capability  functions 

Standards 

The  design  for  solutions  articulating  the  Performers,  Activities,  Services,  and  their 
Exchanges,  providing  for  or  supporting  operational  and  capability  functions 

Systems 

The  design  for  solutions  articulating  the  systems,  their  composition,  interconnectivity, 
and  context  providing  for  or  supporting  operational  and  capability  functions 

Figure  2  is  a  visual  representation  of  the  multiple  DoDAF  viewpoints  and  the 
relationships  between  them. 
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Figure  2.  DoD  Architecture  Framework  Viewpoint  relationships  (From  U.S. 

Department  of  Defense,  2007,  Vol.  2,  p.  140) 
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As  both  an  organization  and  an  enterprise  it  is  logieal  to  structure  the  JTB  in 
accordance  with  DoDAF,  however  only  Operational  Viewpoints  and  System  Viewpoints 
were  produced  as  part  of  the  research  for  this  thesis. 

a.  Operational  Viewpoints 

Operational  viewpoints  are  used  to  describe  a  DoD  organization  by 
graphically  depicting  the  tasks,  activities,  and  operations  performed  by  that  organization. 
Developing  operational  viewpoints  can  assist  the  organization  by  linking  functional 
requirements  to  the  organization’s  activities.  There  are  nine  models  associated  with 
Operational  Viewpoints  as  described  in  Table  6. 

Table  6.  Operational  Viewpoint  Models  (From  U.S.  Department  of  Defense,  2007,  Vol.  2, 

p.  162) 


Model 

Description 

OV-l:  High-Level 

Operational  Coneept  Graphie 

The  high-level  graphieal/textual  deseription  of  the  operational  eoneept 

OV-2:  Operational  Resouree 
Flow  Deseription 

A  deseription  of  the  Resouree  Flows  exehanged  between  operational 
aetivities 

OV-3:  Operational  Resouree 
Flow  Matrix 

A  deseription  of  the  resourees  exehanged  and  the  relevant  attributes  of  the 
exehanges 

OV-4:  Organizational 
Relationships  Chart 

The  organizational  eontext,  role  or  other  relationships  among 
organizations 

OV-5a:  Operational  Aetivity 
Deeomposition  Tree 

The  eapabilities  and  aetivities  (operational  aetivities)  organized  in  a 
hierarehal  stmeture 

OV-5b:  Operational  Aetivity 
Model 

The  eontext  of  eapabilities  and  aetivities  (operational  aetivities) 
and  their  relationships  among  aetivities,  inputs,  and  outputs; 

Additional  data  ean  show  eost,  performers  or  other  pertinent  information 

OV-6a:  Operational  Rules 
Model 

One  of  three  models  used  to  deseribe  aetivity  (operational  aetivity).  It 
identifies  business  rules  that  eonstrain  operations 

OV-6b:  State  Transition 
Deseription 

One  of  three  models  used  to  deseribe  operational  aetivity  (aetivity).  It 
identifies  business  proeess  (aetivity)  responses  to  events  (usually,  very 
short  aetivities) 

OV-6e:  Event-Traee 
Deseription 

One  of  three  models  used  to  deseribe  aetivity  (operational  aetivity).  It 
traees  aetions  in  a  seenario  or  sequenee  of  events 
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Once  these  models  are  developed  they  can  be  used  to  describe  an  organization  in 
a  simple  logieal  architecture.  This  description  can  be  used  by  the  organization’s  decision 
makers  to  assist  in  developing  requirements,  operating  concepts,  and  proeesses. 

b.  System  Viewpoints 

Systems  Viewpoints  are  used  to  deseribe  how  the  systems  an  organization 
uses  support  the  organization’s  functions.  The  System  Viewpoint  models  are  designed  to 
associate  the  operational  viewpoint  aetivities  and  display  the  exchange  of  information 
between  those  activities.  The  thirteen  System  Viewpoint  models  are  described  in  Table 

7. 


Table  7.  System  Viewpoint  Model  (From  U.S.  Department  of  Defense,  2007,  Vol  2,  p. 

201) 


Models 

Descriptions 

SV-1  Systems  Interface 
Description 

The  identification  of  systems,  system  items,  and  their  interconnections 

SV-2  Systems  Resource  Flow 
Description 

A  description  of  Resource  Flows  exchanged  between  systems 

SV-3  Systems-Systems  Matrix 

The  relationships  among  systems  in  a  given  Architectural  Description.  It  can 
be  designed  to  show  relationships  of  interest,  (e.g.,  system-type  interfaces, 
planned  vs.  existing  interfaces). 

SV-4  Systems  Functionality 
Description 

The  functions  (activities)  performed  by  systems  and  the  system  data  flows 
among  system  functions  (activities). 

SV-5a  Operational  Activity  to 
Systems  Function  Traceability 
Matrix 

A  mapping  of  system  functions  (activities)  back  to  operational  activities 
(activities). 

SV-5b  Operational  Activity  to 
Systems  Traceability  Matrix 

A  mapping  of  systems  back  to  capabilities  or  operational  activities  (activities). 

SV-6  Systems  Resource  Flow 
Matrix 

Provides  details  of  system  resource  flow  elements  being  exchanged  between 
systems  and  the  attributes  of  that  exchange. 

SV-7  Systems  Measures 

Matrix 

The  measures  (metrics)  of  Systems  Model  elements  for  the  appropriate 
timeframe(s). 

SV-8  Systems  Evolution 
Description 

The  planned  incremental  steps  toward  migrating  a  suite  of  systems  to  a  more 
efficient  suite,  or  toward  evolving  a  current  system  to  a  future  implementation. 

SV-9  Systems  Technology  & 
Skills  Forecast 

The  emerging  technologies,  software/hardware  products,  and  skills  that  are 
expected  to  be  available  in  a  given  set  of  time  frames  and  that  will  affect 
future  system  development. 

SV-lOa  Systems  Rules  Model 

One  of  three  models  used  to  describe  system  functionality.  It  identifies 
constraints  that  are  imposed  on  systems  functionality  due  to  some  aspect  of 
system  design  or  implementation. 

SV-1  Ob  Systems  State 

Transition  Description 

One  of  three  models  used  to  describe  system  functionality.  It  identifies 
responses  of  systems  to  events. 

SV-lOc  Systems  Event-Trace 
Description 

One  of  three  models  used  to  describe  system  functionality.  Identifies  system- 
specific  refinements  of  critical  sequences  of  events  described  in  the  OV. 
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III.  METHODOLOGY 


A.  INTRODUCTION 

To  meet  the  thesis  objeetives  the  researeher  needed  to  identify,  eapture,  and 
understand  the  interaetion  between  the  end  user  and  the  JTB.  This  was  eompleted  by 
performing  researeh,  ineluding  eondueting  a  literature  review  (Chapter  II),  eondueting 
interviews  with  proeess  partieipants,  using  an  arehiteeture  development  tool  to  represent 
this  information,  and  using  the  software  tool  to  analyze  the  interaetions. 

B.  INTERVIEWS  WITH  SUBJECT  MATTER  EXPERTS 
1,  Developing  the  Interview  Questions 

a.  Development  of  Questions 

The  questions  for  the  interviews  were  developed  to  eapture  the  most 
information  in  an  hour,  so  as  not  to  disrupt  the  work  sehedules  of  partieipants.  Interview 
questions  were  developed  through  a  dialogue  between  the  researeher  and  the  thesis 
advisors.  Final  questions  were  seleeted  in  order  to  ensure  the  participants’  answers 
would  be  focused  upon  the  information  sharing  processes  within  the  JTB  enterprise. 

b.  Interview  Questions 

Table  8  contains  the  questions  that  were  asked  of  the  participants  with 
respect  to  information  flow. 

Table  8.  Information  Flow  Questions 

Which  nodes/activities  within  the  JIEDDO  Test  Board  (JTB)  do  you  interact 

with? _ 

How  often  do  you  interact  with  these  nodes/activities? 

(Daily/Weekly/Monthly/Other) _ 

What  type  of  information  is  passed  from  you  to  other  nodes  within  the  JTB? 

What  type  of  information  is  passed  to  you  from  other  nodes  within  the  JTB? _ 

How  do  you  pass  the  information  to  other  nodes  within  the  JTB? _ 

How  do  you  receive  information  from  other  nodes  within  the  JTB? 
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Table  9  contains  the  questions  that  were  asked  of  the  participants  with 
respect  to  information  usage. 


Table  9.  Information  Usage  Questions 


Can  you  sketch  the  information  flow  within  the  JTB  from  your  vantage  point? 

How  do  other  nodes  within  the  JTB  communicate? 

What  type  of  products  do  you  produce  or  publish? 

What  type  of  products  do  you  obtain  or  use? 

Do  you  use  SIPRnet? 

How  often  do  you  access  SIPRnet? 

Do  you  access  the  JTB  SIPRnet  web  portal? 

How  often  do  you  access  the  portal? 

What  information  do  you  access  on  the  portal? 

Who  generates  the  information  on  the  portal? 

What  information  do  you  need  on  the  portal  that  is  currently  not  there  but  available 
elsewhere?  (i.e..  Testing  site  portals) 

Have  you  received  training  on  the  portal? 

Did  training  include  a  review  of  the  information  available  on  the  portal? 

Did  the  training  include  procedures  of  how  to  access  information  on  the  portal? 

How  do  you  use  the  NIPRnet? 

How  is  this  process  efficient?  What  is  missing? 

How  is  this  process  inefficient?  What  is  missing? 

The  questions  in  Table  10  were  used  to  refine  the  information  provided 
thus  assisting  to  produce  accurate  models. 

Table  10.  Information  Refinement 

Process:  What  happens  inside  this  activity/node? _ 

Input:  What  documents,  online-data,  or  discussions  do  you  need  to  begin  this  process? 

What  information,  very  roughly,  do  these  give  you? _ 

Output:  What  documents,  information  systems,  or  discussions  does  this  node  produce? 

Trigger:  What  triggers  communication  with  this  node:  a  schedule  and/or  an  event? _ 

Periodicity:  Is  this  node  performed  continuously  or  on-demand? _ 

Periodicity:  How  active  is  this  node  ( _ times  per _ hr/day/wk/mo/yr)?  Please  state  a 

range  from  low  to  high  frequency? _ 

Duration:  How  long  does  it  take  to  execute  this  node? _ 

Flow/Precedence:  Does  this  node  happen  in  parallel  with  other  nodes?  Which  nodes? 
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2. 


The  Interview  Process 


The  research  process  used  for  this  thesis  included  receiving  Institutional  Review 
Board  approval,  determining  the  interview  participants,  and  developing  the  interview 
questions. 


a.  The  Institutional  Review  Board 

The  methods  used  to  gain  information  were  in  accordance  with  the  Naval 
Postgraduate  School  Internal  Review  Board. 

b.  Participant  Selection 

It  was  determined  that  conducting  interviews  with  members  of  the  JTB 
Enterprise,  to  include  subject  matter  experts  (SME)  from  organizations  within  or 
associated  with  the  JTB,  would  be  able  to  provide  the  best  description  of  the  current 
processes  of  the  JTB.  All  participants  interviewed  were  recommended  by  the  JTB  as 
each  participant  had  experience  and  knowledge  about  different  aspects  of  the  JTB 
Enterprise. 


c.  Interview  Procedure 

The  researcher  met  with  participants  in  a  quiet  setting  beneficial  to 
conducting  an  interview.  The  period  of  time  spent  with  each  participant  varied,  due  to 
the  participants’  subject  area  and  knowledge  of  the  JTB  as  well  as  the  participants’ 
willingness  to  talk.  The  interview  took  an  average  of  one  hour  to  complete,  however 
some  interviews  lasted  longer  due  the  nature  of  the  participant’s  expertise.  Interviews 
were  recorded  (when  permitted)  to  prevent  any  loss  of  information  provided  by  the 
participant.  These  interviews  proved  crucial  in  capturing  critical  information  on  each 
participant’s  organization  or  activity.  In  addition,  several  of  the  participants  had  recently 
been  deployed  to  Afghanistan  and  Iraq  where  they  served  as  convoy  leaders  and  faced 
lED  threats.  These  participants  were  interviewed  to  determine  how  the  JTB  and  its 
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products  and  services  are  utilized  by  the  end  users.  Interviews  were  conducted  in  person, 
which  required  travel  to  the  various  organizations  and  testing  sites  assoeiated  with  the 
JTB  enterprise. 

The  researeher  traveled  to  interview  participants  at  the  various  loeations 
within  the  JTB  Enterprise.  Interviews  were  condueted  with  the  partieipant(s)  and 
researcher  seated  in  a  quiet  room  with  the  door  closed.  Participants  were  informed  about 
the  nature  of  the  researeh  and  given  eonsent  forms  to  sign  (the  participants  were  assured 
that  names  would  not  be  used).  Participants  were  also  informed  that  if  there  were  any 
questions  which  caused  any  undue  stress  they  did  not  need  to  answer.  Onee  the  forms 
were  signed  partieipants  were  asked  the  questions  on  information  flow  in  Table  8  and  9. 
After  answering  those  questions  the  partieipant  was  then  asked  the  questions  in  table  10, 
depending  upon  the  progress  of  the  researeh  at  the  time  the  partieipant  were  shown 
representative  models  of  the  JTB  Enterprise  and  the  JTB  REI  Proeess,  and  asked  to 
comment  and/or  eorrect  the  model. 

d.  Transcription 

Partieipants  were  asked  if  the  interview  could  be  reeorded;  most  agreed, 
however  some  did  not.  Some  of  the  interviews  were  transeribed  to  ensure  that  all 
applicable  information  provided  by  the  participants  was  used. 

3.  Obstacles  to  the  Interview  Process 

Several  obstaeles  had  to  be  overeome  throughout  the  interview  process.  In  one 
instance  the  interview  was  eonducted  in  a  seeure  facility  that  restricted  the  use  of 
personal  eleetronie  deviees  so  the  interview  eould  not  be  reeorded.  In  other  instances 
some  participants  answered  with  short  simple  answers,  such  as  merely  a  “yes”  or  “no,” 
providing  little  insight.  Another  obstacle  was  that  some  participants  declined  to  be 
reeorded;  this  was  either  due  to  the  participant’s  status  as  a  contractor,  or  to  the 
participant’s  unease  with  the  interview  proeess.  In  all  interviews,  time  was  taken 
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immediately  after  the  interview  eoneluded  to  write  down  information  the  partieipant  had 
provided  during  the  interview  to  ensure  the  maximum  amount  of  information  was 
retained. 

C.  IMPLEMENTING  DODAF 

It  beeame  evident  that  in  order  to  analyze  the  JTB  from  the  end  user  perspeetive, 
the  JTB  Enterprise  would  not  only  need  to  be  doeumented  but  the  results  of  the  interview 
proeess  would  need  to  be  displayed  in  a  manner  that  would  provide  all  personnel 
assoeiated  with  the  JTB  the  means  to  fully  understand  the  enterprise.  To  aceomplish  this, 
the  objeetive  was  to  graphieally  display  the  JTB  Enterprise  and  the  assoeiated  proeesses 
using  the  Department  of  Defense  Arehiteeture  Eramework  (DoDAE).  Results  of  the 
interview  proeess  were  entered  into  a  software  tool,  OpenText’s  Provision.  Provision 
provides  the  eapability  to  model  the  entire  JTB  Enterprise,  and  to  simulate  any  proeess 
models  developed.  Training  was  reeeived  on  the  use  of  software  tool  (Provision),  which 
included  how  to  enter  data  collected  during  the  interviews  into  the  tool  in  order  to 
develop  the  Operational  Viewpoints  and  System  Viewpoint. 

1.  Developing  Models 

The  DoDAE  models  chosen  to  represent  the  JTB  Enterprise  consist  of  three 
Operational  Viewpoints  (OV-1,  OV-4,  and  OV-6)  and  one  System  Viewpoint  (SV-1). 
These  four  models  best  describe  the  JTB  Enterprise,  keeping  within  the  scope  of  the 
research.  The  OV-1  and  the  OV-4  were  completed  by  using  the  information  gathered 
during  the  interview  process  as  an  input  to  the  software  tool.  The  OV-1  was  developed  to 
show  a  broad  overview  of  a  JTB  Process  and  how  the  end  users  and  the  JTB  conduct  the 
JTB  REI  Process.  The  OV-4  was  developed  to  depict  the  relationships  and  interactions 
the  JTB  has  with  the  organizations  included  in  the  JTB  Enterprise.  The  OV-6  was 
developed  and  refined  then  used  to  model  the  JTB  REI  Process.  The  JTB  REI  Process  is 
not  the  only  testing  process  the  JTB  executes,  however  it  was  selected  as  the  process  to 
represent  the  JTB  Enterprise  as  it  is  performed  within  the  JTB  Enterprise.  Other 
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processes,  over  whieh  the  JTB  has  some  authority  in  aoeordanee  with  the  DoD  Direetive 
2000.19,  include  JIEDDO  initiatives;  however,  those  proeesses  involve  organizations 
outside  the  scope  of  the  researeh.  The  SV-1  was  developed  to  represent  the  users  of  the 
JTB  portal.  The  SV-1  was  developed  by  using  the  partieipant’s  answers  to  the  interview 
questions. 

2.  Simulating  the  OV-6  Model 

Once  the  models  were  developed  additional  information  was  obtained  through  the 
JTB  Portal.  The  information  obtained  from  the  JTB  Portal  eonsisted  of  statistieal  data  on 
the  JTB  RFl  Proeess.  The  statistieal  analysis  entailed  gathering  the  number  of  RFls  the 
JTB  reeeived  in  the  year  2010.  Eaeh  RFl  was  examined,  in  terms  of  the  time  taken  to  be 
resolved  and  the  manner  of  resolution.  This  information  was  used  in  the  OV-6  to  refine 
the  sourees,  destinations,  aetivities  and  decision  points  of  the  OV-6.  The  model  eould 
then  be  aeeurately  simulated.  The  parameters  used  to  run  the  simulation  eonsisted  of  one 
hundred  runs  times  over  a  one  year  time  frame  and  was  based  on  the  reeommendations  of 
one  of  the  thesis  advisors.  These  parameters  allowed  the  model  to  be  exeeuted  multiple 
times  of  the  eourse  of  a  year,  whieh  would  provide  assistanee  to  determine  the  flow  of 
information  through  the  JTB  Enterprise  and  display  aetivities  where  the  information  may 
be  impeded  or  delayed. 
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IV.  RESULTS 


Through  the  interviews  and  statistieal  researeh  it  was  diseovered  that  the  JTB  is 
an  Enterprise  eontained  within  the  larger  JIEDDO  Enterprise.  This  is  signifieant  sinee 
many  of  the  roles  assoeiated  with  enterprises  (sueh  as  human  resourees  or  payroll)  are 
administered  by  the  parent  JIEDDO  Enterprise;  this  makes  the  JTB  Enterprise  unique  as 
it  only  needs  to  focus  upon  its  tasking.  The  answers  given  in  the  interview  process 
provided  the  data  needed  to  develop  the  DoDAE  models  which  have  been  designed  to 
provide  situational  awareness  to  the  JTB  regarding  the  flow  of  information  and  the  end 
user  role  in  the  enterprise. 

A,  OPERATIONAL  VIEWPOINT  (OV-1)  OF  THE  JOINT  lED  DEFEAT 

TEST  BOARD  REQUEST  FOR  INFORMATION  PROCESS 

The  purpose  of  an  Operational  Viewpoint  1  (OV-1)  is  to  give  an  overview  as  to 
how  a  process  or  organization  is  aligned  and  display  its  lines  of  communication.  Figure  3 
is  an  OV-1  depicting  the  top-level  flow  of  information  during  the  JTB  RFI  Process  as  it 
passes  through  the  major  activities  in  the  JTB  Enterprise.  Each  of  the  organizations 
included  in  the  OV-1  has  the  ability  to  generate  a  Request  for  Information  (RFI)  should 
an  event  occur  or  these  organizations  need  information  required  to  conduct  mission 
tasking.  This  research  is  primarily  focused  on  the  end  users,  which  can  be  any  of  the  five 
organizations  displayed  on  the  right  side  of  Figure  3.  The  Theater  Operating  Forces,  such 
as  US  Forces  Iraq  and  the  Multinational  Forces- Afghanistan,  are  the  final  end  users  of  the 
JTB  process  and  products. 

The  JTB  can  have  either  a  direct  or  indirect  effect  upon  these  end  users.  A  direct 
effect  occurs  when  these  end  users  generate  an  RFI.  An  RFI  is  generated  by  submitting 
the  RFI  through  the  Theater  Support  Web  Tool  (TSWT)  or  by  making  contact  with  either 
JTF  Paladin  or  JTF  Troy  and  having  either  of  those  two  organizations  generate  an  RFI  for 
them.  Once  generated,  the  RFI  follows  the  information  flow  as  illustrated  in  Figure  3, 
passing  once  again  through  either  JTF  Paladin  or  JTF  Troy  to  the  end  user. 
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F igure  3 .  JIB  Overview  (O V - 1 ) 
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JTF  Paladin  and  JTF  Troy  work  with  forces  within  their  respective  theater  of 
operations  to  provide  training  or  develop  proeesses  and  proeedures.  These  proeesses  and 
proeedures  are  then  implemented  in  the  field  by  Battalion  Eleetronic  Warfare  Offieers 
(EWO)  to  assist  in  the  protection  of  EiS  and  Coalition  Eorces.  Under  these  circumstanees 
JTE  Paladin  and  JTE  Troy  act  as  the  end  user.  In  these  situations  an  REI  generated  by 
JTE  Paladin  or  JTE  Troy  is  also  terminated  at  JTE  Paladin  and/or  JTE  Troy.  The 
information  from  the  REI  could  then  be  passed  to  the  operating  forees  in  theater,  whieh  is 
an  example  of  a  situation  where  the  JTB  has  an  indireet  effeet  upon  the  theater  operating 
forces. 

The  Combined  Theater  Eleetronic  Warfare  Command  Center  (CTEWCC)  is  an 
integral  and  foeal  point  of  the  REI  process.  CTEWCC  acts  as  a  filter  for  REIs  and  other 
CIED  information  as  it  colleets  inputs  from  all  relevant  organizations  within  the  AOR 
and  provides  prioritization  of  testing  requirements  to  the  JTB.  CTEWCC  is  also  tasked 
with  assisting  in  confiiet  resolution.  If  conflicts  occur  between  any  of  these  theater 
organizations  that  eannot  be  resolved,  the  CTEWCC  Commander  has  the  authority  to 
make  a  final  determination.  The  JTB  will  not  accept  any  test  priorities  from  CENTCOM 
organizations  without  first  coordinating  with  CTEWCC.  The  key  for  CTEWCC  is  to 
build  relationships  with  the  commanders  or  officers  in  charge  of  the  theater  task  forees 
and  eoordinate  a  unity  of  effort  between  them.  This  in  turn  will  provide  additional 
support  when  they  request  it  (for  example,  to  ghostwrite  REIs  or  even  write  them 
completely  when  they  don't  have  time).  In  this  manner  CTEWCC  is  the  Supporting 
Command  whilst  JTE  Paladin  and  JTE  Troy  along  with  the  other  end  users  are  the 
Supported  Commands. 

Once  an  REI  has  cleared  through  CTEWCC  it  is  forwarded  to  the  JTB,  who 
determines  method  of  testing  which  is  to  be  utilized  to  resolve  the  RFI.  Three  general 
methods,  or  types,  of  testing  are  used  for  REI  resolution;  laboratory  testing,  modeling  and 
simulation  testing,  and  open  air  testing.  At  this  point  it  is  up  to  the  JTB  to  determine 
whieh  method  is  most  benefieial;  in  some  eases  more  than  one  method  is  used.  Onee  the 
method  of  testing  is  assigned  to  a  specific  REI  it  is  then  scheduled,  planned,  and  tested  by 

that  organization.  Upon  completion  of  testing  a  test  report  is  written  and  approved  by  the 
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testing  organization  and  then  posted  to  the  JTB  web  portal.  This  portion  of  the  process  is 
very  well  organized  and  efficient  and  has  led  to  the  successful  testing  of  over  three 
hundred  RFIs,  adhering  to  the  guidance  set  forth  for  the  JTB  in  the  DoD  Directive  which 
states  it  will  “synchronize  and  coordinate  all  JIEDDO  counter  lED  testing  efforts.” 

Results  of  the  testing  are  compiled,  and  a  test  report  is  written  and  posted  to  the 
JTB  Portal,  located  on  the  SIPRnet.  Elpon  uploading  the  test  report  to  the  portal,  the 
Knowledge  Information  Network  Group  (KING)  uses  the  data  in  the  report  to  generate  a 
product  for  the  end  users  which  displays  the  effectiveness  of  the  CIED  equipment  that 
was  tested.  Test  reports  and  other  related  JTB  products  available  on  the  JTB  Portal  can 
be  downloaded  and  utilized  by  the  different  theater  support  elements.  It  should  be  noted 
that  information  on  the  JTB  Portal  is  pulled  by  the  user,  rather  than  pushed  to  all  parties 
involved. 

B,  THE  JTB  ENTERPRISE 

Using  the  results  of  the  interview  process  a  DoDAE  model  was  developed  using 
the  Provision  software  tool.  This  Operational  View  is  an  organizational  model,  more 
commonly  known  as  an  OV-4.  The  OV-4  encompasses  and  displays  the  JTB  as  an 
Enterprise  displaying  the  organizations  and  activities  which  the  JTB  has  either  direct 
authority  over,  or  has  built  a  strong  relationship  with,  to  accomplish  the  mission  of  the 
JTB. 


1.  Structure  of  the  JTB 

The  Joint  lED  Defeat  Test  Board  (shaded  gray  and  green  in  Eigure  4)  is 
located  in  three  locations  accessible  to  the  Washington,  DC  Metro  area:  Crystal  City,  VA, 
Alexandria,  VA  (ATEC  South  facility),  and  Aberdeen,  MD  (ATEC  North  facility);  the 
majority  of  the  personnel  are  located  in  Alexandria,  VA.  The  JTB  organization  follows  a 
hierarchical  staff  structure  with  a  Chairperson  and  a  Director  and  then  is  further 
segmented  into  various  functional  areas,  such  as  the  Support  and  the  Operations 
divisions.  The  JTB  operates  within  and  across  these  different  functional  areas 


28 


necessitating  a  robust,  knowledge  dependent  organization.  In  order  to  fulfill  the  many 
duties  assigned  to  the  JIB,  contractors  have  been  hired  to  provide  specialized  assistance 
and  expertise. 

The  JTB  also  employs  the  use  of  working  groups  (shaded  orange  in  Figure 
4).  These  working  groups  consist  of  subject  matter  experts  (SMEs)  who  collaborate  and 
provide  recommendations  to  the  JTB  Director,  such  as  testing  protocols.  There  are 
currently  eight  working  groups;  Knowledge  Management,  Information  Technology, 
Threats,  Test  Operations,  Advanced  Communications,  Foreign  Disclosure,  and  Electronic 
Attack  Clearance.  The  working  groups  are  also  consistent  with  the  functional  areas 
conducted  within  the  JTB. 
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2,  Organizations  Associated  with  the  JTB 

Many  organizations  are  associated  with  the  JTB.  Figure  4  is  not  all  inclusive,  as 
the  JTB  has  the  ability  to  use  a  multitude  of  resources  in  order  to  comply  with  its  tasking. 
In  Figure  4  the  organizations  associated  with  the  JTB  are  linked  to  the  JTB  Director  with 
a  dashed  line,  the  dashed  line  represents  the  relationship  between  the  JTB  and  the  various 
organizations  as  a  working  relationship  rather  than  a  hierarchical  relationship.  Of  these 
organizations  with  ties  to  the  JTB  some  are  used  more  often  than  others,  yet  all  are 
important  as  each  organization  provides  a  specific  asset  which  the  JTB  can  utilize,  thus 
maximizing  the  effort  while  supporting  the  end  user. 

a.  Testing  Agencies 

The  JTB  employs  the  use  of  many  different  testing  agencies  which  include 
open-air  testing,  laboratory  testing  and  modeling  and  simulation  organizations.  Each 
organization  offers  a  different  means  for  the  JTB  to  accomplish  its  mission.  The  JTB 
counts  on  these  organizations  for  specific  tasking;  it  is  the  specificity  that  assists  the  JTB 
in  decreasing  redundancy  in  testing  which  is  directed  in  the  DoD  directive.  The  use  of 
multiple  testing  agencies  also  gives  the  JTB  flexibility  to  conduct  many  concurrent  tests. 

(1)  Open  Air  Testing  Facilities.  Open  air  testing  plays  a  vital  role 
in  JTB’s  ability  to  provide  quality  products  to  the  end  user.  The  open  air  testing  sites 
employed  by  the  JTB  include  but  are  not  limited  to  Yuma  Proving  Grounds  (YPG), 
Naval  Air  Weapons  Station  China  Lake  (China  Lake),  and  White  Sands  Missile  Range 
(WSMR).  Each  of  these  sites  has  the  ability  to  replicate  any  environment  JTB  testing 
requires  including  electromagnetic,  temperature  and  urban/rural  environments.  These 
open  air  sites  also  have  the  ability  to  manipulate  the  test  environment  in  order  to  simulate 
the  true  environment  where  the  result  of  the  test  will  be  used.  Testing  environments  are 
developed  in  accordance  with  specific  criteria  obtained  from  a  Request  for  Information 
(RLI),  a  vendor’s  specifications,  or  test  protocols  set  forth  by  the  JTB. 

(2)  Laboratories  and  Universities.  Laboratories  and  universities 
offer  the  JTB  a  means  to  conduct  testing  in  a  controlled  environment.  Laboratories  offer 
the  JTB  the  ability  to  test  not  only  equipment  but  protocols  and/or  procedures  as  well. 
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This  is  advantageous  to  the  JTB  and  the  end  user  sinee  this  testing  ean  often  be  eondueted 
quiekly  and  at  a  lower  eost  than  open  air  testing.  Testing  at  the  different  laboratories  and 
universities  may  also  eonsist  of  modeling  and  simulation  (M&S).  The  ability  to  develop 
and  exeeute  models  affords  the  JTB  another  avenue  for  effective  testing  at  a  lower  cost 
than  open  air  testing. 

b.  Theater  Elements 

(1)  End  User.  The  end  user  (shaded  light  brown  in  Figure  4)  is  the 
war  fighter.  In  this  sense  the  end  users  are  the  members  of  the  Armed  Services  who,  by 
the  nature  of  their  work,  are  in  close  proximity  to  the  lED  threat.  The  end  users  utilize 
JTB  products  which  are  passed  to  them  via  Battalion  Headquarters,  turnover  of 
equipment  with  other  users,  or  other  theater  operational  support  elements.  The  end  users 
receive  the  JTB  products  and  put  them  into  practice  when  operating  in  a  region  where  the 
possibility  of  encountering  an  lED  is  elevated.  The  end  users  have  their  lives  on  the  line 
and  are  dependent  upon  the  effectiveness,  as  well  as  the  availability  of,  the  products 
produced  by  members  of  the  JTB. 

(2)  Theater  Operational  Support.  Theater  operational  support 
elements  include  the  different  organizations  that  fall  within  the  JTB’s  scope  of 
operations.  The  JTB  relies  on  many  organizations  to  ensure  testing  conducted  is  relevant 
to  the  end  user  as  well  as  ensure  the  end  user  has  the  proper  JTB  products  in  order  to 
succeed.  One  such  organization  is  the  Combined  Theater  Electronic  Warfare  Control 
Center  (CTEWCC),  described  in  section  A  of  this  chapter.  Other  theater  support 
elements  consist  of  JTF  Paladin  and  JTF  Troy  and  the  JTB  Forward  Operating  and 
Assessment  (FOA)  teams.  Each  of  these  organizations  works  with  both  the  end  users  and 
the  JTB  to  ensure  testing  is  relevant  and  the  priority  of  the  test  is  understood.  These 
elements  also  have  the  capability  to  submit  RFIs  to  the  JTB  through  the  TSWT. 
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c. 


THE  JTB  RFI  PROCESS 


Many  processes  are  incorporated  within  the  JTB  while  aecomplishing  its  mission, 
sueh  as  payroll  and  other  monetary  proeesses,  however,  the  seope  of  this  researeh  was  to 
foeus  upon  the  end  user.  The  JTB  RFI  Process  was  ehosen  to  represent  the  interactions 
of  the  JTB  Enterprise  as  it  is  includes  the  end  user.  The  JTB  RFI  Process  model  was 
developed  to  be  displayed  as  a  DoDAF  OV-6  in  order  to  be  simulated,  and  simulation 
results  are  intended  to  provide  an  aecurate  representation  of  the  proeess.  Figures  5 
through  8  depict  the  JTB  RFI  process. 
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Figure  5. 
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Figure  8.  The  JTB  RFI  Process 
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1. 


Activities  and  Decision  Points 


The  JTB  RFI  Process  (shown  in  Figures  5-8)  consists  of  nineteen  activities.  Each 
activity  represents  an  action  taken  by  an  organization  within  the  JTB  enterprise.  The 
organizations  are  arranged  horizontally  while  the  sequences  of  the  process  have  the 
ability  to  move  both  horizontally  and  vertically.  Tables  11  and  12  describe  the  activities 
and  decision  points  contained  within  the  OV-6. 

a.  JTB  RFI  Process  A  ctivities 

The  JTB  RFI  Process  contains  19  activities  that  are  described  in  Table  11. 


Table  1 1 .  JTB  RFI  Process  Activities 


Activity 

Description 

Generate  RFI 

Once  an  end  user  or  theater  support  personnel  have  determined  a  need 
for  information,  the  Theater  Support  Web  Tool  (TSWT)  is  utilized  in 
order  to  generate  a  request  for  information. 

RFI  Status:  Open 

The  status  of  an  RFI  becomes  open  once  it  has  been  submitted  through 
the  TSWT. 

Submit  Documentation 

Proper  documentation  is  located  and  posted  to  the  JTB  Portal  and  sent 
to  generator  of  RFI 

Compatibility  Test 
Planning 

During  the  test  planning  phase  information  is  gathered,  based  upon  RFI 
input,  and  test  is  scheduled  and  planned  based  upon  current  protocols. 

Compatibility  Test 
Execution 

Execution  of  compatibility  testing  occurs  once  the  test  plan  has  been 
developed  and  permission  has  been  granted. 

Compatibility  Test 
Report 

Upon  completion  of  compatibility  testing,  an  initial  quick-look  is 
generated  and  submitted  to  all  subscribers  of  the  RFI.  Also  an  official 
test  report  is  drafted  and  submitted  for  approval.  Once  approved  the 
test  report  is  posted  to  the  JTB  SIPRnet  web  portal. 

Performance  Test 
Planning 

During  the  test  planning  phase  information  is  gathered,  based  upon  RFI 
input,  and  test  is  scheduled  and  planned  based  upon  current  protocols. 
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Activity 

Description 

Performance  Test 
Execution 

Execution  of  performance  testing  occurs  once  the  test  plan  has  been 
developed  and  permission  has  been  granted. 

Performance  Test 

Report 

Upon  completion  of  performance  testing,  an  initial  quick-look  is 
generated  and  submitted  to  all  subscribers  of  the  RFI.  Also  an  official 
test  report  is  drafted  and  submitted  for  approval.  Once  approved  the 
test  report  is  posted  to  the  JTB  SIPRnet  web  portal. 

Lab  Test  Planning 

During  the  test  planning  phase  information  is  gathered,  based  upon  RFI 
input,  and  test  is  scheduled  and  planned  based  upon  current  protocols. 

Lab  Test  Execution 

Execution  of  laboratory  testing  occurs  once  the  test  plan  has  been 
developed  and  permission  has  been  granted. 

Lab  Test  Report 

Upon  completion  of  laboratory  testing,  an  initial  quick-look  is 
generated  and  submitted  to  all  subscribers  of  the  RFI.  Also  an  official 
test  report  is  drafted  and  submitted  for  approval.  Once  approved  the 
test  report  is  posted  to  the  JTB  SIPRnet  web  portal. 

M  &  S  Test  Planning 

During  the  test  planning  phase  information  is  gathered,  based  upon  RFI 
input,  and  test  is  scheduled  and  planned  based  upon  current  protocols. 

M  &  S  Test  Execution 

Execution  of  modeling  and  simulation  testing  occurs  once  the  test  plan 
has  been  developed  and  permission  has  been  granted. 

M  &  S  Test  Report 

Upon  completion  of  modeling  and  simulation  testing,  an  initial  quick- 
look  is  generated  and  submitted  to  all  subscribers  of  the  RFI.  Also  an 
official  test  report  is  drafted  and  submitted  for  approval.  Once 
approved  the  test  report  is  posted  to  the  JTB  SIPRnet  web  portal. 

Post  Test  Report  to  JTB 
Portal 

Once  testing  is  completed  the  testing  agency  posts  the  report  to  the  JTB 
Portal  in  order  to  provide  information  to  the  JTB  Enterprise. 

JTB  review 

JTB  inputs  test  report  data  to  database 

Theater  Support 

Review 

Theater  support  elements  review  and  disseminate  information  to  end 
users 
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Activity 

Description 

Utilization 

End  users  apply  results  and  modify  TTPs  based  upon  new  information 

b.  JTB  RFI  Process  Decision  Points 


The  process  also  contains  four  decision  points,  which  are  described  in 

table  12. 


Table  12.  JTB  RFI  Process  Decision  Points 


Decision  Point 

Description 

Is  RFI  Valid? 

CTEWCC  determines  the  validity  of  the  request.  If  the  RFI  is  deemed 
to  be  a  valid  request  it  is  then  sent  to  the  JTB  for  further  determination 
of  the  manner  in  whieh  the  RFI  will  be  resolved. 

Does  RFI  Require 
Testing? 

This  is  determined  by  JTB  personnel.  A  no  deeision  leads  to  the  RFI 
being  resolved  by  sending  doeumentation  to  the  generator  of  the  RFI, 
for  example  the  doeumentation  eould  be  a  previously  published  Test 
Report  or  a  publieation  from  the  manufaeturer.  A  no  deeision  eould 
also  lead  to  a  study  eondueted  in  an  aeademie  setting.  A  yes  answer 
leads  to  other  deeision  points  to  determine  the  type  of  testing.  If  more 
information  is  required  to  determine  testing  type  or  proeedures,  the  RFI 
originator  is  eontaeted  in  order  to  answer  questions. 

What  type  of  testing  is 
needed? 

This  deeision  is  used  to  determine  how  the  RFI  will  be  resolved.  The 
options  inelude:  open  air  testing,  laboratory  testing,  or  modeling  and 
simulation. 
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Decision  Point 

Description 

Compatibility/ 
Performance  testing 

If  it  is  decided  that  open  air  testing  will  be  conducted  the  RFI  is  then 
forwarded  to  an  open  air  facility  to  conduct  either  compatibility  or 
performance  testing.  This  decision  is  determined  by  the  information 
given  in  the  RFI. 

2.  Sequence  of  the  JTB  RFI  Process 

The  process  is  started,  once  a  need  for  information  is  determined  by  either  an  end 
user  or  a  member  of  a  theater  support  system.  An  RFI  is  generated  within  the  Theater 
Support  Web  Tool  (TSWT)  on  the  SIPRnet  (which  was  considered  to  be  accessible  by  all 
participants  involved  in  the  interview  process).  Upon  submitting  the  RFI  the  status  is 
switched  to  “Open”  and  sent  to  CTEWCC  for  review  as  CENTCOM  has  mandated  that 
all  JTB  RFI  requests  from  CENTCOM  AOR  will  be  passed  through  and  approved  by 
CTEWCC.  CTEWCC  then  determines  the  validity  of  the  request.  If  the  RFI  is  deemed 
to  be  a  valid  request  it  is  forwarded  to  the  JTB  for  further  determination  of  the  manner  in 
which  the  RFI  will  be  resolved.  In  this  way  CTEWCC  acts  as  a  filter  between  the  JTB 
and  the  theater  support  systems/end  users. 

The  JTB  receives  the  RFI  and  its  priority  (assigned  by  CTEWCC)  via  notification 
by  the  TSWT.  JTB  personnel  determine  how  the  RFI  will  be  resolved.  If  it  is  decided 
that  testing  is  not  required,  documentation  (such  as  a  prior  test  report  and/or  a 
manufacturer’s  manual)  is  sent  to  the  generator  of  the  RFI.  If  the  RFI  requires  testing  it 
is  forwarded  to  one  of  the  test  agencies,  which  leads  to  other  decision  points  to  determine 
the  type  of  testing.  The  “else”  decision  is  used  in  case  the  RFI  is  deemed  invalid  and  thus 
closed.  If  more  information  is  required  to  determine  testing  type  or  procedures,  the  RFI 
originator  is  contacted  to  obtain  clarification. 

The  next  decision  is  to  determine  if  the  RFI  will  be  resolved  using  an  open  air  test 
range,  a  lab,  or  modeling  and  simulation.  In  any  of  the  three  cases  the  testing  has  been 
broken  down  to  three  essential  activities.  The  first  is  the  planning  portion  of  the  testing. 
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The  test  agency  will  plan  and  schedule  the  test  in  accordance  with  protocols  set  forth  by 
the  JTB  and  the  RFI.  The  test  sites  use  this  time  to  reach  out  to  the  RFI  generator  or 
CTEWCC  should  any  questions  arise.  This  is  an  invaluable  step  as  it  ensures  the  testing 
is  planned  and  executed  to  provide  the  best  support  the  end  users.  The  next  two  steps  of 
the  RFI  process  (Test  Execution  and  Test  Report)  are  performed  by  the  test  agency, 
however  the  JTB  is  heavily  involved  as  it  monitors  and  synchronizes  the  testing  during  a 
weekly  video  teleconference  (VTC)  with  members  of  the  enterprise  as  well  as  members 
of  JIEDDO.  With  the  testing  completed  the  test  agency  posts  the  test  report  to  the  JTB 
web  portal  for  all  interested  parties  to  view.  The  data  within  the  test  report  is  then  used 
by  the  Knowledge  Information  Networking  Group  (KING)  to  generate  products  which 
can  be  easily  interpreted  by  the  end  user  and  viewed  on  the  TSWT. 

3.  JTB  RFI  Process  Simulation  Results 

In  2010,  the  JTB  responded  to  55  RFIs.  Overall,  the  average  time  from  RFI 
initiation  to  a  response  available  to  the  end  user  was  16  days.  However,  the  response 
time  varied  greatly  and  was  dependent  upon  on  the  method  used  to  resolve  the  RFI.  The 
amount  of  time  for  a  given  activity  was  derived  from  the  statistical  research,  and  the 
distribution  of  those  times  was  based  upon  a  statistical  analysis  of  the  number  of  RFI 
submitted  in  a  calendar  year  and  the  amount  of  time  taken  to  resolve  the  RFI.  Table  13 
displays  the  results  of  the  statistical  analysis  conducted  on  the  number  of  RFIs  submitted 
in  2010.  The  standard  deviation  for  the  open  air  and  the  modeling  and  simulation  RFIs  is 
larger  than  the  average  time  taken  to  resolve  the  RFI  due  to  the  wide  disparity  in  the 
number  of  days  taken  for  RFI  resolution. 


Table  13.  Results  of  JTB  RFI  Statistical  Analysis 


Type  of  resolution 

#  RFI's 

Average  time  to 
resolution  (in  Days) 

Standard 

Deviation 

Paper/Lab  Resolved 

18 

13.75 

12.2632118 

Open  Air  Resolved 

27 

13.74074074 

17.43910855 

Mod/Sim  Resolved 

9 

32.88888889 

43.2274347 

Academic  Analysis  Resolved 

1 

4 

0 
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Figure  9  depicts  the  result  of  the  JTB  RFI  Process  simulation.  It  shows  the 
average  time  spent  at  each  of  the  activities.  The  information  entered  into  each  of  the 
activities  was  based  upon  the  data  in  Table  13.  The  OV-6C  captured  in  the  Provision  tool 
can  easily  be  adjusted  to  reflect  changes  to  the  RFI  process  or  to  any  of  the  activities 
within  the  JTB  RFI  Process.  These  changes  normally  take,  at  most  a  few  hours  of  effort. 
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Figure  9.  RFI  Process  Simulation  Result 
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D.  DESCRIPTION  OF  THE  SYSTEM  VIEWPOINT 


The  system  viewpoint  is  used  to  illustrate  how  users  access  the  JTB  Portal. 


Figure  10.  JTB  Portal  System  Viewpoint- 1 

Figure  10  depicts  the  users  of  the  JTB  Portal.  The  JTB  Portal  is  structured  as  an 
Oracle  database  hosted  at  the  Yuma  Proving  Grounds.  Members  of  the  theater  support 
systems  use  the  portal  to  gain  information  to  assist  in  their  development  of  procedures  to 
be  implemented  in  their  Area  of  Operations.  Members  of  the  working  groups  have  access 
to  an  area  of  the  portal  that  can  be  utilized  to  post  information.  The  testing  agencies  also 
have  access  to  post  the  test  reports  and  pull  the  information  needed  to  support  executed 
testing.  The  JTB  Knowledge  Information  Networking  Group  (KING)  designed  the  portal 
and  also  administers  its  use.  However,  it  is  also  a  user  of  the  portal  as  it  develops  JTB 
Products  after  the  test  reports  are  posted. 

The  JTB  Portal  contains  links  to  other  relevant  websites  and  portals  associated 
with  the  JTB  Enterprise.  For  example  the  TSWT  is  a  separate  web  portal.  Therefore, 
separate  accesses  are  required  in  order  to  utilize  all  of  the  tools  available  to  the  users. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  goal  of  this  thesis  is  to  analyze  end-user  interaction  with  the  JTB,  to  support 
developing  recommendations  for  improving  this  interaction.  An  architectural  process 
capture  method  was  used  to  identify  key  activities  and  support  the  analysis  reported  in 
this  chapter,  and  is  based  on  the  literature  review,  which  suggests  three  key  elements  to 
operating  a  successful  process  in  support  of  war  fighters.  Those  elements  are 
organizational  structure,  collaboration,  and  the  related  information  sharing  that  can  best 
support  the  end  user.  The  findings,  conclusions,  and  recommendations  of  this  chapter  are 
based  upon  an  analysis  of  the  JTB  Enterprise  with  respect  to  the  three  key  elements. 
Since  the  interaction  with  the  end  user  is  most  important,  that  activity  analysis  begins  this 
discussion. 

A,  IMPACT  OF  THE  JTB  ON  THE  END  USER 

The  interaction  between  the  JTB  and  the  end  user  is  both  direct  and  indirect. 
Direct  interaction  occurs  through  tools  such  as  the  Theater  Support  Web  Tool  (TSWT), 
which  provides  the  mechanism  for  the  end  user  to  input  a  Request  for  Information  (RFI). 
The  TSWT  also  affords  the  end  user  the  ability  to  track  the  status  of  the  request  to  its 
resolution.  The  JTB  also  has  direct  interaction  with  the  end  user  through  pre-deployment 
training  provided  to  the  Electronic  Warfare  Officers  (EWO).  Training  includes 
information  about  the  purpose  of  the  JTB  and  products  developed.  Indirect  interaction 
occurs  through  the  theater  support  elements  (which  could  also  be  end  users)  as  these 
elements  use  the  information  gathered  from  a  resolved  REI  to  develop  guidelines  and 
procedures,  which  in  turn  are  used  by  the  end  users. 

Until  recently  the  theater  support  elements  had  a  direct  means  of  communication 
with  the  end  users.  Initially,  EWOs  from  the  Navy  and  the  Air  Eorce  were  first  assigned 
to  the  theater  support  elements  and  then  the  theater  support  element  units  to  whom  the 
EWOs  were  assigned  would  embed  the  EWOs  within  deployed  units.  This  gave  the 
theater  support  elements  a  means  of  constant  interaction  with  the  end  users.  However, 
presently  the  Army  has  increased  its  cadre  of  EW  officers,  replacing  the  Navy  and  Air 
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Force  EWOs,  and  these  Army  EWOs  are  now  organie  to  deployed  units.  While  this 
different  dynamie  has  not  eompletely  severed  the  flow  of  information  to  and  from  the  end 
users,  it  has  hindered  it. 

It  was  diseovered  through  interviews  with  the  end  users  that  many  of  them  were 
not  familiar  with  the  JTB  but  they  were  familiar  with  JIEDDO.  Elpon  learning  of  the  JTB 
eaeh  of  the  end  users  stated  that  the  tools  available  on  the  JTB  Portal  would  be  useful  in 
the  field,  implying  they  had  not  seen  or  used  the  JTB  Portal  or  other  assoeiated  web  tools, 
sueh  as  the  TSWT.  Based  on  this  researeh  one  reeommendation  is  that  the  JTB  eonduct 
briefs  periodieally  with  EWOs  in  order  to  gain  ideas  to  improve  the  support  and/or 
produets  provided  to  the  end  users.  The  intention  of  these  briefs  would  be  to  initiate  a 
dialogue  with  the  end  users  whieh  would  provide  the  JTB  a  means  to  improve  all 
proeesses  aeross  the  enterprise.  Another  reeommendation  is  to  invite  EWOs  to  attend  the 
weekly  Video  Teleconferenee  (VTC).  EWO  attendanee  would  greatly  increase 
situational  awareness,  and  this  eould  be  implemented  by  simply  having  battalion  EWOs 
attend  early  in  their  rotation,  or  it  eould  be  requested  that  attendanee  to  the  VTC  be  part 
of  the  turnover  proeess. 

JIEDDO  uses  soeial  networking  as  a  means  to  provide  information  to  assoeiated 
and  interested  personnel  aeross  its  enterprise.  This  may  also  be  a  vehicle  for  the  JTB  to 
improve  its  visibility  to  the  end  user.  Having  a  soeial  networking  site  gives  the  JTB  the 
ability  to  broadeast  pertinent  information  to  all  personnel  assoeiated  with  the  JTB.  This 
soeial  networking  site  could  also  be  used  to  inerease  awareness  about  the  JTB  sinee  it  is 
not  required  to  be  assoeiated  with  the  JTB  Enterprise  in  order  to  be  a  member  of  the  JTB 
soeial  networking  site. 

B,  ANALYSIS  OF  THE  JTB  ENTERPRISE 

The  JTB  Enterprise  eonsists  of  relationships  whieh  have  existed  since  the  JTB 
was  formed  in  2006.  As  with  any  Enterprise,  the  JTB  Enterprise  eontains  organizations 
over  whieh  the  JTB  has  no  direet  authority.  In  these  eases  the  JTB  has  established 
working  relationships,  however  there  is  no  established  guidanee  or  written  poliey  that 
speeifies  the  nature  of  the  relationship.  The  eurrent  relationships  with  the  test  sites  are 
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established  through  eontraets,  however  these  eontraets  exist  only  between  the  JTB  and 
the  test  site.  Guidanee  that  ineludes  and  deseribes  the  relationships  between  the 
organizations  for  the  entire  enterprise  would  inerease  situational  awareness  aeross  the 
enterprise. 

1.  Organizational  Structure  Analysis  of  the  JTB  Enterprise 

The  strueture  of  the  JTB  enterprise  is  aligned  with  three  of  the  organizational 
struetures  deseribed  by  Mintberg  and  diseussed  in  Chapter  II.  The  JTB  enterprise 
eombines  the  flexibility  of  the  simple  strueture,  the  standardization  of  skills  of  the 
professional  bureaueraey,  and  the  ability  to  eommunieate  aeross  domains  of  the 
adhoeraey.  The  JTB  Enterprise  is  a  flexible  enterprise  mainly  due  to  the  nature  of  the 
tasks  whieh  are  being  eondueted  by  eaeh  of  the  aetivities  of  the  enterprise.  The 
environments  the  test  sites  are  repheating  are  dynamie  and  the  flexibility  to  adapt  and 
ehange  has  proven  to  be  a  tremendous  strength  of  the  JTB  Enterprise.  It  is  not 
uneommon  for  a  test  to  be  planned  and  exeeuted  in  a  matter  of  days.  This  remarkable 
response  time  is  aehieved  through  existing  working  relationships,  whieh  have  been 
forged  over  time.  However,  should  any  of  the  personnel  exit  the  JTB  enterprise  then  that 
line  of  eommunioation  eould  be  severed  resulting  in  a  loss  of  flexibility.  To  maintain 
sueh  flexibility,  a  set  of  guidelines  or  poliey  should  be  developed  whieh  promotes  the 
growth  of  trust  amongst  people  from  the  different  organizations  within  the  JTB 
enterprise. 

Standardization  of  skills,  as  in  the  professional  bureaueraey,  has  been  maximized 
by  separating  the  type  of  testing  eondueted  at  eaeh  of  the  test  sites.  This  division  of  labor 
has  resulted  in  an  inereased  level  of  speeialization  at  the  test  sites,  whieh  has  mitigated 
redundaney  in  testing,  one  of  the  hve  areas  of  authority  given  to  the  JTB  by  the  DoD 
Direetive.  Relianee  upon  the  operating  eore,  that  is,  the  test  sites,  and  its  ability  to 
operate  autonomously  is  another  eharaeteristie  whieh  indieates  the  JTB  Enterprise 
operates  as  a  professional  bureaueraey.  The  independent  environment  of  the  professional 
bureaueraey  eahs  for  little  eoordination  or  formalization  between  eaeh  of  the 
speeializations  of  the  operating  eore.  It  is  the  JTB  that  provides  a  means  to  eoordinate 
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and  collaborate  through  use  of  the  JTB  Portal,  as  seen  in  Figure  10,  whieh  depiets 
members  of  the  operating  eore  and  the  lines  of  eommunieation  to  the  JTB  Portal. 

Communieating  aeross  domains,  whieh  refers  to  the  way  organizations  internet  in 
an  adhoeraey,  may  not  be  the  ideal  method  for  the  JTB  Enterprise.  Communieation  is  an 
essential  attribute  of  organizations,  however  if  the  test  sites  were  to  begin  eoordinating 
without  JTB  oversight  information  eould  be  lost  and  testing  may  beeome  redundant. 

The  JTB  Enterprise  falls  within  the  Coordination  quadrant  of  Eigure  1,  as  the 
enterprise  is  eomprised  of  distinetive  organizations  that  require  aeeess  to  shared 
information.  The  JTB  Portal  is  the  means  the  JTB  has  eleeted  to  provide  shared 
information  to  the  JTB  Enterprise. 

2.  Organizational  Relationships  within  the  JTB  Enterprise 

Information  gathered  from  the  interviews  provided  the  bulk  of  the  information 
used  to  develop  the  OV-4,  and  were  essential  to  understanding  the  existing  relationships 
in  the  JTB  Enterprise.  However,  the  interviewees  expressed  a  eommon  eoneem 
regarding  a  laek  of  communieation  within  the  enterprise,  which  was  attributed  to  the  faet 
they  did  not  know  who  or  how  to  eontaet  other  members  of  the  enterprise.  This  laek  of 
eommunieation  eould  be  mitigated  by  keeping  an  updated  point  of  eontaet  (POC)  list. 
Developing  and  publishing  a  POC  list  eould  prove  to  be  a  daunting  task,  yet  onee 
eompiled  it  eould  be  invaluable,  in  terms  of  fostering  an  inerease  in  eommunieation 
throughout  the  enterprise.  Due  to  the  rate  of  turnover  of  personnel  within  the  enterprise, 
it  is  reeommended  that  the  POC  list  be  evaluated  and  updated  on  a  quarterly  basis. 
Consideration  should  also  be  given  to  posting  this  POC  list  on  the  JTB  portal. 

Working  groups  are  manned  by  subjeet  matter  experts  in  the  field  related  to  their 
respeetive  working  group,  and  are  formed  by  the  authority  of  the  JTB  Direetor.  The  JTB 
working  groups  provide  a  eritical  and  useful  service  in  the  development  of  testing 
protocols.  Currently  there  is  no  guidance  governing  the  strueture  of  the  working  groups. 
Using  the  discussion  boards  located  on  the  JTB  Portal  to  post  information  for  eaeh  of  the 
working  groups  would  help  ensure  that  the  latest  protocols  are  used  in  the  testing  proeess 
to  provide  the  best  support  to  the  end  user. 
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3,  Final  Analysis  of  the  JTB  Enterprise 

One  glaring  omission  from  the  JTB  Enterprise  is  the  position  of  a  Chief 
Information  Officer  (CIO)  or  a  Chief  Technology  Officer  (CTO).  It  is  recommended  that 
a  CIO/CTO  be  appointed  and  given  authority  to  institute  policies  and  protocols  which 
would  govern  the  massive  amounts  of  information  produced  by  the  test  agencies.  Each 
test  report  is  written  with  the  same  structure,  however  most  if  not  all  of  the  data  is  held  by 
the  agency  conducting  the  test.  A  CIO/CTO  with  authority  could  compile  the  data  in  a 
manner  that  would  be  useful  to  the  Enterprise  and  assist  in  ensuring  there  is  no 
redundancy  in  testing,  as  stated  in  the  Directive.  The  JTB  Enterprise  can  be  used  as  an 
example  of  an  organizational  structure  for  many  DoD  as  well  as  non-DoD  organizations, 
since  the  level  of  complexity  of  the  organization  has  been  mitigated  by  using  specialists 
to  perform  their  tasks  while  the  JTB,  which  is  the  strategic  apex  of  the  enterprise, 
provides  the  oversight  required  for  the  entire  enterprise  to  perform  its  duties. 

C.  THE  JTB  PROCESS  ANALYSIS 

The  JTB  REI  Process  is  efficient.  Erom  2006  through  2010,  over  three  hundred 
REIs  have  been  processed.  However,  it  is  not  the  number  of  REIs  that  have  been 
processed  that  is  impressive,  it  is  the  flexibility  and  swiftness  in  which  the  REIs  are 
tracked  and  resolved.  The  flexibility  of  the  REI  Process  allows  an  REI  to  be  prioritized 
and  executed  in  a  short  amount  of  time,  giving  time-critical  results  to  the  end  user.  The 
process  spans  the  entirety  of  the  JTB  Enterprise  as  each  member  of  the  Enterprise 
contributes  to  a  portion  of  the  process.  These  contributions  range  from  personnel 
conducting  tests  to  personnel  generating  REIs  to  budget  analysts. 

1,  JTB  Process  Collaboration 

Collaboration  in  the  JTB  REI  Process  is  essential  for  the  process  to  support  the 
end  user.  The  meaning  of  collaboration  is  to  work  together  and  the  structure  of  the  JTB 
REI  Process  encompasses  the  entire  JTB  Enterprise,  thus  capitalizing  on  the  expertise  of 
the  personnel  involved.  Weekly  VTCs  support  collaboration  as  all  the  stakeholders  of  the 
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JTB  Enterprise  as  well  as  members  of  JIEDDO  are  able  to  provide  information  to  eaeh 
other.  These  VTCs  help  to  provide  situational  awareness  regarding  the  status  of  JTB  RFI 
Proeess. 

The  JTB  RFI  Proeess  depieted  in  Figures  5-8  ineludes  only  four  deeision  points; 
however  other  decisions  are  made  at  various  points  of  the  process  within  some  of  the 
activities.  These  decisions  are  made  by  the  subject  matter  experts  and  are  vetted  through 
the  rest  of  the  JTB  RFI  Process  stakeholders  at  the  weekly  SVTC.  The  collaborative 
environment  of  the  JTB  RFI  Process  has  been  evolving  into  this  current  state  which  is 
effective,  and  as  it  continues  to  evolve  it  will  increase  its  product  and  support  thus  giving 
the  end  users  a  competitive  advantage  over  their  adversaries. 

2,  JTB  Process  Recommendations 

The  process  may  be  efficient;  however,  there  are  a  few  areas  where  it  can  be 
improved.  Currently,  there  is  no  policy  governing  the  process;  the  only  information 
uncovered  regarding  the  RFI  Process  was  a  TSWT  user  manual  which  is  located  on  the 
SIPRnet.  The  user  manual  provides  instruction  on  generating  an  RFI.  It  also  provides  a 
description  of  the  process,  yet  the  authority  to  execute  the  process  is  nonexistent.  While 
it  may  seem  trivial  to  have  a  policy  written  which  would  restate  what  is  currently 
happening,  a  written  policy  would  be  beneficial  to  the  end  users  as  it  would  inform  all 
participants  of  the  process  that  occurs  in  each  of  the  activities.  This  policy  can  then  lead 
to  the  JTB  RFI  Process  certification.  Certifying  the  process  could  give  the  JTB  the 
flexibility  to  interchange  personnel  without  disrupting  the  JTB  RFI  Process. 

Another  recommendation  is  to  institute  a  tracking  mechanism  for  the  RFI  Process, 
which  can  be  implemented  by  updating  the  RFI  submission  form.  Currently  the 
submission  form  does  not  offer  a  means  to  input  any  personal  information,  such  as  an  e- 
mail  address.  The  ability  to  provide  an  e-mail  address  to  be  attached  to  the  RFI  as  it 
traverses  the  process  gives  everyone  associated  with  that  RFI  an  efficient  way  to  reach 
out  to  the  person  who  submitted  the  RFI  to  gain  further  information  (if  required).  A 
tracking  mechanism  could  also  provide  a  way  for  the  person  who  submitted  the  RFI  to 
receive  automatic  status  updates  at  different  RFI  Milestones,  such  as  when  it  is  resolved. 
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It  would  also  prove  useful  if  the  end  user,  more  specifieally  the  EWOs,  eould 
have  a  statie  email  address  assigned  by  the  JTB.  A  statie  email  address  that  would  be 
turned  over  between  personnel,  would  improve  the  lines  of  eommunication.  This  email 
address  eould  be  used  by  the  JTB  to  reach  out  to  the  end  user  should  questions  arise 
about  an  RFI. 

D,  THE  JTB  PORTAL 

The  JTB  Portal  was  analyzed  while  conducting  the  research  needed  for  the 
development  of  the  OV-6.  The  portal  has  useful  links  to  the  organizations  associated 
with  the  JTB  Enterprise.  A  username  and  password  are  required  to  access  the  Portal,  thus 
controlling  access;  however  each  of  the  websites  needed  for  the  REI  Process  requires 
different  usernames  and  passwords.  A  single  sign-on  portal  would  allow  one  to  generate 
an  RFI  within  one  session.  The  portal  also  has  discussion  boards  for  each  of  the  working 
groups  to  use  for  collaboration;  however  most  are  not  used  nor  had  been  used  in  over  a 
year.  A  CIO/CTO,  as  recommended  earlier  in  this  chapter,  given  proper  authority  could 
require  the  use  of  the  message  boards  and  the  portal.  The  use  of  the  JTB  Portal  would 
provide  a  central  point  for  all  information  generated  by  the  JTB  Enterprise  to  flow.  The 
Portal  has  the  potential  to  become  a  relevant  source  of  information  to  the  end  user,  yet 
without  policy  or  a  public  relations  campaign  it  will  continue  to  be  a  useful  tool  that  goes 
unused. 

E,  AREAS  FOR  FUTURE  RESEARCH 

The  models  that  have  been  developed  for  this  research  were  intended  to  uncover 
and  make  explicit  the  interactions  of  the  JTB  with  the  end  users,  however  the  models  can 
offer  much  more  than  a  display  of  the  information  flow  used  for  the  JTB  RFI  Process. 
The  software  tool  used  to  develop  the  models  includes  algorithms  which  can  analyze 
other  variables,  most  notably  cost.  The  JTB  RFI  Process  can  be  manipulated  to  conduct 
“what  if’  analyses,  such  as  updating  each  of  the  activities  to  reflect  its  monetary  value. 
Analysis  of  this  nature  could  be  used  in  determining  the  cost  of  the  current  process.  Once 
cost  is  established  the  model  can  then  be  used  to  determine  ways  to  resolve  RFIs  in  a  way 
that  is  more  fiscally  efficient.  Cost  is  not  the  only  variable  that  can  be  manipulated;  the 
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efficiency  of  the  model  can  also  be  analyzed,  in  order  to  develop  alternative  methods 
which  would  increase  the  level  of  support  to  the  end  user. 


F.  FINAL  ANALYSIS 

The  JTB  as  an  Enterprise  and  an  organization  is  efficient  and  adheres  to  the 
guidance  set  forth  by  the  DoD  Directive.  Documenting  the  JTB  Enterprise,  its  people, 
processes,  and  products,  and  instituting  guidance  to  govern  the  enterprise  will  be  essential 
to  the  JTB  Enterprise  as  it  continues  to  counter  the  dynamic  threat  by  El.S.  adversaries. 
This  will  become  increasingly  important  as  the  Elnited  States  withdraws  forces  from  the 
Middle  East,  and  the  nature  of  counter  lED  work  evolves  in  the  future. 
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